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any moons ago I visited a stately home that fea- 
M tured a garden maze. Knowing a little topology 

(the geometry of shapes without attention to 
measurement) I thought I knew how to solve garden 
mazes. Smugly I boasted that I would make short work of 
this bit of shrubbery. I walked quickly through the first 
hundred feet or so, using my secret weapon — the ‘left 
hand rule’ — always turning left when possible. 

True, this would take me into each cul-de-sac, but 
would also ensure that I would find the way out of any 
connected two-dimensional maze. Suddenly before me 
was a bridge — and under it another passage, sunk about 
eighteen inches into the ground. This garden maze was 
actually three-dimensional! I eventually emerged a wiser, 
humbler young man. 

This memory came flooding back when I read a letter 
from Andrzej Kwiecinski of Belfast, suggesting an algo- 
rithm for testing whether there is a path out of a 
randomly-created maze in the game Minotaur (see PC 
PLUS issue 67). His algorithm correctly (1 believe) tests 
any connected maze with any number of dimensions; it 
requires the ability to mark doors between cells (or pas- 
sageways between junctions) — perhaps you have some 
thread as Theseus did in the labyrinth. Andrzej sum- 
marised the algorithm in just four steps; this presumes 
that you can make a mark on either side of any door, and 
see it afterwards from either side of the door. 


STEP 1: Choose a cell to start from. 


STEP 2: If there is an unmarked door from the cell you 

are in, choose one, mark it, walk through it to the adja- 
cent cell and go to (the start of) STEP 2. If every door is 
already marked (on either side) go to STEP 3. 


STEP 3: If there are any doors marked on only one side, 
choose one of them, mark it a second time, walk through 
it to the adjacent cell and go to STEP 2. If every door is 
already marked on both sides, go to STEP 4. 


STEP 4. You have visited all the cells of the maze accessi- 
ble from here; if you didn’t see the exit on the way, too 
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bad — you will starve! 


If the cell has both an entrance and an exit, you can start 
at STEP 1 while at the entrance: you will eventually get to 
the exit — or STEP 4! You will never get lost in an endless 
loop, because (as we defined in Minotaur) there are a 
maximum of 768 doors. Even if you pass through all of 
them twice before finding the exit, that’s only 2,306 steps. 
Andrzej gives credit where it is due — to Leonhard Euler 
(1707-1783), a blind Swiss mathematical genius who 
developed the idea behind this algorithm while trying to 
determine whether anybody could cross each of the 
seven bridges of the town of Konigsberg once only. 

Andrzej goes on to show how the algorithm can be 
adapted to create a maze instead of test one, thereby 
guaranteeing that there is a solution. He then suggests 
some ingenious ways of building blind alleys and red 
herrings into the maze just created, making it longer (if 
not more difficult) to solve. How about a simple maze- 
generating program using this method, with all sorts of 
blind alleys for fun? Even a two-dimensional maze gener- 
ator (easier to represent on screen or paper) will test 
programming skills. 


PI IN THE SKY 

T Frogley of Stansted, Essex, takes me to task for suggest- 
ing that 355/113 is a pretty good estimate for pi Gssue 
70); he unkindly observes ‘you don’t know much about 
maths’ and states ‘any true mathematician would have 
used the correct way to calculate pi, which is 4*ATN() — 
this gives pi to a 16-digit accuracy’. 

That’s not so; it gives pi perfectly — the accuracy deter- 
mined only by your compiler’s limitation on calculating 
ATN(1). I didn’t say 355/113 is a way of calculating pi — 
just that it is a good estimate; it requires only one small 
calculation (a simple division) and two small numbers 
(each of which can be recorded in a single word). I men- 
tioned it as a far better estimate than 22/7 (the one they 
used to teach in secondary schools when I was younger); 
the next fraction that is better than this is the rather 
rotund 86598/27565. 

Using 4*ATN(1) — or even hard-coding a long decimal 
expression — is all very well, but using a simple multipli- 
cation and a division involving two integers uses less 
memory and is much faster; if you had to do the calcula- 
tion over and over you would see the difference; using 
the precalculated fraction takes only 38 percent of the 
time the calculation takes (using GW-Basic on a 386). 

I have devised a program — I won't bore you with the 
maths behind it — that will convert any decimal constant 
you choose into a pair of whole numbers to use in this 
way; you can then incorporate them into your programs 
to speed up calculations. I shall find room on the 
SuperDisk to include it in the near future. Here are a few 
examples that may be of use: 


(a) to convert kilograms to pounds: multiply by 959 5 
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and divide by 435. 


(b) to compute the VAT portion (at 17.5 percent) of a 
net price: multiply by 7 and divide by 40. 


WHAT AM I? 

Alastair Varnais (Sonning Common, near Reading) asks 
whether I know of any way a program can determine the 
processor type on which it is running — or at least to dis- 
tinguish between an XT and an AT. The answer, I am 
glad to say, is yes — as long as you can readily use assem- 
bler instructions in the language of your choice. The 
method I present here (below) actually tests for minor 
differences between the processor types; I have used it 
often and have not had any complaints of it failing. There 
was not enough room for it on the SuperDisk this month, 
but we may fit it on next month’s disk. In the meantime 
you can construct a file with this code and feed it into 
DEBUG to create a tiny program WHATPROC.COM, 
which will set ERRORLEVEL to a number indicating the 
type of processor: zero for XT; two for 80286; three for 
80386; four for 80486. Feel free to modify this code so 
that it is a function called from a main program, passing 
back an integer value. 


The differences tested are as follows: 


(a) an XT will lose the top bit of the stack segment 
pointer if it popped back into the AX register. 


(b) an 80286 processor does not use flag bit E; we can 
distinguish it from more powerful processors by observ- 
ing this bit not working. 

(c) both 80386 and 80486 processors have extended reg- 
isters (such as EAX and EBX), but the 80386 does not use 
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extended flag bit 12h. 
This code is a DEBUG script: name it WHATPROC.BUG 
and use it as a command stream by keying: 


DEBUG <WHATPROC. BUG 


This will create the program WHATPROC.COM, a modest 
88 bytes long. The information starting with the semi- 
colon on each line is comment, illustrating what’s going 
on; you need not key it. The ‘DB 66’ and ‘DW 4’ entries 
are used to simulate instructions on the 80386 and 80486 
processors that cannot be generated directly by DEBUG. 


BLOOMSDAY CALENDAR 

In PC PLUS issue 71 I announced that three Scots had 
been the first to identify Thursday 16 June 1904 as 
Bloomsday (from the novel Ulysses). 

Since then I have seen two other winners — Stuart 
Smith (New Milton, Hants) and Steve Williamson 
(Sheffield), who will receive the new command language 
FROMBAT, from Clockwork Software. 

Steve’s Basic program helped confirm that Bloomsday 
was a Thursday. It gave three pieces of information: 

1. The first day of 1904 is a Friday 

2. 16 June 1904 is a Thursday 

3. A calendar for June 1904 (Steve — look again at that 
calendar; there seems to be a little problem with it). 

Making calendars is not difficult but errors in the sim- 
ple calculations are always possible; back in 1967 a 
prominent encyclopaedia in the US had a ‘perpetual cal- 
endar’ chart in their new edition; it proved a great 
embarrassment to them that their calendar was wrong for 
three out of every four years before 1956. For your study 
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and amusement, above is a program that works correctly 
between 1 January 1900 and 31 December 1999. It 
requires you to key in values in DD/MM/YY format, so I 
call it DDMMYY. 

This program thoroughly vets the input fields, making 
sure the date entered is valid: you cannot confuse matters 
by keying decimal places in DD, MM or YY, either. 

The main ‘tricks’ can be seen in the following lines: 
570: P is set to incorporate the day of the month, plus 
one day for each year since 1900, plus an extra day for 
each leap year; this is because each year is 52 weeks plus 
one day long — or two days for leap years. This calcula- 
tion keeps pace with the day of the week affected by the 
DD and YY portions of the date. 


620: This line adds 0 (for January) or 3 (for February) to 
P, giving our new calculation, Q. Note that February starts 
three days later than January in each year 


630-640: This adds six days in the case of January or 
February of leap year; this effectively backs up one day 
in the week — because these two months are ‘pushed 
back’ by 29 February. 


690: This line calculates how the months (between March 
and December) affect the day of the week; note that 30.6 
is the average length of a month. 


700: For all months, this line changes a number into a 
single digit for the day of the week; for example 234 
would become 3 because 234 days is 24 weeks plus three 
days. In some languages, this can be done quite easily 
with an operation called ‘modulo’. 

Why not incorporate this code into a more complex 
program — for example to print a standard calendar? 


BITS AND PIECES 

I have in hand lots of interesting questions, tips and pro- 
jects from various readers — including Pawel Kokot 
(Cieszyn, Poland) and young Paul Emerton (Bathwick, 
Avon) — but I have only a few pages each month to fill; 
look in each month, and we will get around to your area 
of interest. I avidly read all letters, whether or not I men- 
tion them here immediately. Please remember that there 
is approximately a two-month gap between my writing 
this column and its appearance.@ 


Tips, arguments and ideas are gratefully received by: 


Wilfs Programmer’s Workshop 
PC PLUS Magazine 
4 Queen Street 

BATH BA1 1EJ 
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